Sign-on service and client service information exchange interactions

ABSTRACT

Techniques are described for providing customizable sign-on functionality, such as via an access manager system that provides single sign-on functionality and other functionality to other services for use with those services&#39; users. The access manager system may maintain various sign-on and other account information for various users, and provide single sign-on functionality for those users using that maintained information on behalf of multiple unrelated services with which those users interact. The access manager may allow a variety of types of customizations to single sign-on functionality and/or other functionality available from the access manager, such as on a per-service basis via configuration by an operator of the service, such as co-branding customizations, customizations of information to be gathered from users, customizations of authority that may be delegated to other services to act on behalf of users, etc., and with the customizations that are available being determined specifically for that service.

This application is also related to U.S. patent application Ser. No.______ (Attorney Docket #120137.521), filed concurrently and entitled“Enhanced Security For Messaging,” which is hereby incorporated byreference in its entirety.

TECHNICAL FIELD

The following disclosure relates generally to techniques for providingcustomizable user sign-on functionality, such as via a single sign-onservice that provides customizable sign-on processes to users of otherservices that are customers of the single sign-on service.

BACKGROUND

Use of computers in daily life has become ubiquitous, such as to enableusers to access and use a variety of types of remote services over theInternet (e.g., via Web sites) or via other access mechanisms (e.g.,cellphone networks). For example, some such services may provide varioustypes of information (e.g., current news or reference material), whileothers may provide a variety of types of activities and capabilities(e.g., online banking, online shopping, email or other messagingservices, etc.). While some services may provide information andcapabilities to anyone, many others are restricted to authorized users,such as to protect the privacy of user information by making itavailable only to authorized users (e.g., to require a user to login toa email service before making the user's email available), to manageuser data used for the activities being performed (e.g., for an onlinemerchant to store financial and shipping information for a user tofacilitate the user's shopping, such as part of an account maintainedfor the user), and to ensure that users have provided appropriatepayment or satisfied other conditions for use of the service.

In order to be able to sign on (or “logon” or “login”) to a service todemonstrate authorization to access restricted information orfunctionality, users must typically first register with the service andobtain appropriate sign-on information (e.g., a username and password)unique to that service. However, as such services proliferate that eachhave unique sign on information, users are inconveniently forced toremember numerous distinct sets of sign-on information for differentInternet sites. In addition, many operators of Internet sites and otherproviders of such services would prefer to be relieved of the burden ofproviding functionality to enable such sign on of user and to maintainuser sign-on and other authentication data.

In an attempt to address these situations, single sign-on systems havebeen created in which a user creates a single set of sign-on informationthat enables access to a group of multiple affiliated services orsystems. Unfortunately, current single sign-on systems have a variety ofproblems. For example, many operators of services are reluctant to usesign-on functionality provided by another operator. This reluctance maybe due to a lack of consistency in the users' experience wheninteracting with the sign-on system (e.g., due to a lack of consistentbranding or other consistent appearance and functionality), becauseavailable sign-on systems may not provide functionality that is desired,etc. In addition, service operators and users may have concernsregarding security, such as fears that imposters may be able toimpersonate a user or service operator in interactions with the singlesign-on system and thus improperly obtain access to restrictedinformation or functionality.

Thus, it would be beneficial to provide techniques to improve singlesign-on services and to provide other benefits.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A-1C illustrate examples of various types of interactions betweenan access manager system, services and users.

FIGS. 2A-2E illustrate examples of interactions between an accessmanager and a service acting as a customer of the access manager inorder to customize functionality to be provided to users of the customerservice.

FIGS. 3A-3B illustrate examples of a customized sign-on process providedby the access manager to users on behalf of a customer service.

FIG. 4 is a block diagram illustrating an example embodiment of anaccess manager server computing system.

FIG. 5 is a flow diagram of an example embodiment of a CustomerRegistration Manager routine.

FIG. 6 is a flow diagram of an example embodiment of a User InteractionManager routine.

FIG. 7 is a flow diagram of an example embodiment of a CredentialManager routine.

FIG. 8 is a flow diagram of an example embodiment of a Customer StatusManager routine.

FIGS. 9A and 9B are flow diagrams of example embodiments of routines forauthenticating received messages.

DETAILED DESCRIPTION

Techniques are described for providing customizable functionality forinteracting with users, such as via an access manager system thatprovides single sign-on functionality and other functionality to otherservices. In some embodiments, an operator of a Web site or otherservice available to users may interact with the access manager systemto customize and otherwise configure single sign-on functionality and/orother functionality that the access manager system will make availableto users of the service. The access manager system may provide suchfunctionality to other services in various ways in various embodiments,such as by enabling initial configuration to be performed by an operatorof a service in an interactive manner and by enabling customizedfunctionality to be provided to users of the service in a programmaticmanner via an API (“application programming interface”) of the accessmanager system. In at least some such embodiments, the access managersystem maintains various sign-on and other account information forvarious users, and provides single sign-on functionality for those usersusing that maintained information on behalf of multiple unrelatedservices with which those users interact. In addition, in at least someembodiments the services on whose behalf the access manager systemprovides the customized functionality are each customers of the accessmanager system, such as for customer services that have previouslyregistered with the access manager system in order to configure thecustomized functionality to be provided (e.g., in exchange for a fee).

In some embodiments, the access manager may allow a variety of types ofcustomizations to single sign-on functionality and/or otherfunctionality available from the access manager. An operator of acustomer service may configure the various types of customizations sothat user interaction with the access manager on behalf of the customerservice is customized for the particular customer service. For example,in at least some embodiments such types of customizations may includevarious types of co-branding for the service to be used by the accessmanager when interacting with users of the service, such as to includevarious information configured for the service with each of one or moregroups of information to be presented to users (e.g., one or more Webpages to be displayed to users), such as one or more indicated images(e.g., logos), indicated text, indicated user-selectable links, otherindicated user-selectable controls (e.g., a displayed menu bar, such asavailable from an indicated URL (“Uniform Resource Locator”) or fromexecuting indicated code), capabilities provided from executingindicated code, etc. In addition, in at least some embodimentscustomizations to functionality available from the access managerinclude various types of information gathering from users of the serviceduring interactions with the access manager, such as to collectinformation from the users based on one or more predefined questionsselected by an operator of the service and/or one or more questionsspecified by the service operator (e.g., demographic information aboutthe user, preference information, information specific to the user foruse by the service in performing its operations, etc.). Co-branding andinformation gathering customizations are discussed in greater detailbelow.

In some embodiments, after a user interacts with the access manager tocomplete a customized sign-on process for a service, the access managerprovides a credential to the service for the user, such as to indicatethat the user is an authorized user for the service and/or to representthe user so that the service may make subsequent requests to performactions on behalf of the user (e.g., to make payments for the user, tomodify stored account information for the user, etc.). The credentialsmay take a variety of forms in various embodiments, such as to includeinformation specific to the user (e.g., a unique username or otheridentifier for the user, an actual name or other identifying informationfor the user, information gathered from the user during the customizedsign-on process, etc.), whether in an encrypted or unencrypted form, orto instead merely be information that the access manager can later mapto the user if returned (e.g., a unique number for the access manager orrelative to a service). In addition, in at least some embodiments, acredential provided to a service on behalf of a user is treated by theaccess manager as being specific to the service, such that a laterrequest to use the credential on behalf of the user will be treated asvalid only if provided by or on behalf of the service. Credentials mayalso have a variety of other types of characteristics in at least someembodiments. For example, a particular credential may be valid for onlya limited period of time and/or for only certain types of activities oroperations on behalf of a user. If so, the access manager may restrictuse of the credentials based on such characteristics. Additional detailsrelated to credentials are discussed below.

In some embodiments, additional types of customizations are allowed bythe access manager for at least some services related to types ofactivities that the services are allowed to take. For example, the typesof actions that some services are allowed to take for their signed-onusers may be limited in various ways, such as to reflect a degree oftrust granted to the service by the access manager—as one example,credentials may in some embodiments be valid for only limited periods oftime, and if so some services may be authorized to refresh their users'credentials to extend their period of validity in at least somecircumstances (e.g., for up to a specified number of times, for up to aspecified total period of validity, in an unlimited and unrestrictedmanner, etc.). In addition, in at least some embodiments, customizationsallowed by the access manager for at least some services include one ormore types of delegation of authority that a primary service may be ableto provide to another secondary service to take actions on behalf of auser, such as to reflect a degree of trust granted by the access managerto the primary service and/or to the secondary service. For example, atleast some primary services to which credentials are provided may beauthorized to delegate authority to other services to use suchcredentials in various ways, including to use the credentials to take atleast some types of actions on behalf of the represented users, toperform refreshing of credentials with limited periods of validity in atleast some circumstances, to request issuance of a new credential forthe user that is specific to the secondary service (e.g., whencredentials are only effective for the service to which they areoriginally issued), etc. Additional details related to types ofdelegation of authority are included below.

The types of customizations that will be made available to a service bythe access manager may be determined in various ways in variousembodiments, such as in an automatic manner based on informationavailable about the service and/or the operator of the service. Forexample, some types of customizations may provide greater security andliability risks if a malicious service (or a malicious party thatattempts to impersonate or otherwise act on behalf of a benign service)is allowed to perform them. With respect to co-branding types ofcustomizations, allowing a service to add text and/or an image to bedisplayed to users carries relatively little risk (assuming that thecontext of the text is not offensive or illegal). Conversely, allowing aservice to specify executable code that the access manager will use whengenerating information to be provided to a user or that will be includedwith the information provided to a user (e.g., a Java applet included aspart of a Web page sent to the user) may carry relatively high risk(e.g., to allow the service-specified code to inappropriately obtaininformation about the user, such as by monitoring sign-on informationprovided by the user to the access manager that would not otherwise beavailable to the service). Additional details related to determiningtypes of customizations to make available to a service are includedbelow.

In addition, in some embodiments various techniques are used to inhibitmalicious parties from performing unauthorized activities, such as toprevent phishing attempts in which malicious parties attempt toimpersonate actual authorized parties. For example, in order to inhibitmalicious users from attempting to interact with the access managerwhile impersonating services authorized to perform such interactions,additional security techniques may be used to authenticate some or allmessages sent from at least some of the services. In particular, in someembodiments each service that is authorized to interact with the accessmanager is given at least one unique secret access key known to theservice and to the access manager, and the secret access key of aservice is then used by the service when sending a message or othercommunication to the access manager so that the access manager canverify that the sender of the message is actually the service. Forexample, each such message from a service may include an indication of aunique identifier for the service, and may also include a digitalsignature that is generated using the secret access key based on atleast a portion of the message contents. When the access managerreceives such a message, the access manager can use the serviceidentifier to identify the service and to retrieve the secret access keyfor that service, and can then generate its own digital signature in thesame manner using the retrieved secret access key and the same portionof the message contents. If the digital signature generated by theaccess manager matches the digital signature included in the message bythe sender, the access manager can verify that the sender has access toboth the unique identifier and the secret access key for the service,and thus it is highly likely that the sender is actually the service. Asecret access key may take a variety of forms in various embodiments,such as a shared secret, a PKI (“Public Key Infrastructure”) key pair,an X.509 certificate, a secret generated using hard tokens, etc. Othersecurity techniques may further be used in at least some embodiments,and additional details regarding the use of secret access keys areincluded below.

For illustrative purposes, some embodiments are described below in whichspecific types of services configure specific types of customizations ofspecific types of functionality provided by an access manager system tospecific types of users of the services in specific manners. However, itwill be appreciated the described techniques can be used in a widevariety of other situations, and that the invention is not limited tothe exemplary details provided.

FIG. 1A illustrates examples of various types of interactions between anaccess manager system, services, and users. In particular, FIG. 1Aillustrates interactions between an access manager system 114, services110 that are customers of the access manager, users 112 of the customerservices, optional other secondary services 118 that are affiliated withthe customer services, and an account manager system 116. In thisexample, the account manager 116 and access manager 114 are bothprovided as part of a group of systems 115 provided by a single entity(e.g., with the account manager performing various actions on behalf ofusers with accounts with the access manager if requests are receivedfrom authorized parties), and in some embodiments at least some of theaffiliated services 118 may also be part of the systems 115. Variousmessages occur between the illustrated systems, services and users, suchas the following: messages between users and the access manager systemas part of establishing accounts for the users (e.g., with sign-oninformation), messages between customer services and the access managerto configure customized functionality for the customer services,messages between users and the customer services (including initialinteractions in which the users are re-directed to interact with theaccess manager to participate in a sign-on process customized to thecustomer services), messages between the customer services and theaccount manager system (e.g., to perform activities on behalf of userswho have signed onto the customer services), messages between thecustomer services and the affiliated secondary services (e.g., toperform activities on behalf of users who have signed onto the customerservices), and messages between the affiliate services and the accessmanager and account manager systems (e.g., on behalf of users who havesigned onto the customer services). In addition, at least some of themessages involving services may use digital signatures (not shown) basedon secret access keys of the services (e.g., messages between thecustomer services 110 and/or affiliate services 118 and the accessmanager 114, account manager 116, and other customer services oraffiliate services).

FIG. 1B illustrates one particular example of various types ofinteractions between an access manager system, services, and users, andin particular illustrates an embodiment in which a customer service isbeing provided by an application of an application developer rather thana Web site. In particular, the application developer 120 (who is named“Bob” in this example) initially registers 180 with the access managersystem 150 for the service to be provided by the developer's application122, such as by interacting with a customer registration process 158 inthis example (e.g., as may be provided by a Customer RegistrationManager component). In this example, the application 122 is anapplication program (e.g., for execution on a general-purpose personalcomputer) that provides services and/or other functionality to end-usersof the application, although in other embodiments such an applicationmay instead have a variety of other forms, such as a Web application, adownloadable applet or other executable code, a client and/or serverapplication, a mobile application (e.g., for execution on a cellulartelephone or other form of mobile computing device), etc. As part ofstep 180, the developer may supply various pieces of information,including contact information and information about the application 122(and optionally a copy of the application). As part of the registrationinteractions 180, the developer may configure various customizations forlater use by end-users of the application, such as co-branding,information gathering, and authority delegation according to a level ofpermissions granted to the developer by the access manager system.Alternatively, some customizations may not be used, such as to notconfigure co-branding if the application will directly interact with anend-user to obtain sign-on information that is then programmaticallysent to the access manager system for verification. In addition, inembodiments such as that illustrated, in which the end-users of theapplication will interact with a graphical user interface provided bythe application 122, the application may be contractually or otherwiseobligated to provide at least some information to the end-users via thegraphical user interface in a particular manner. Such information maybe, for example, related to signing on with the access manager systemthat is presented to end-users in a manner that is co-branded with abrand of the access manager. Alternatively, the application may beobligated to provide other types of information or functionalityspecific to the access manager, and/or to employ various specifiedsecurity measures to protect sign-on information for the end-users.After registration, the developer may receive 181 various informationfrom the access manager, such as an indication of a secret key to beused (or a confirmation of a secret key specified by the developer aspart of the interaction 180) and a non-secret unique identifier for theapplication (e.g., an identifier that is associated with the secretaccess key). After the developer distributes 182 the application tovarious end-users 130, an end-user may use the application to obtainvarious types of functionality.

An example user 130 then interacts 183 with the application, such as byrequesting an operation in which the user will sign-on to use one ormore Web services provided by a remote third-party Web service provider140 (e.g., a Web service provider with which the user has an establishedaccount). Web services may allow heterogeneous applications andcomputers to interact, and can be defined and implemented using avariety of underlying protocols and techniques. For example, some Webservice implementations return data in XML (“eXtensible MarkupLanguage”) format using HTTP (“HyperText Transport Protocol”) inresponse to a Web service invocation request specified as a URI, such asa URL that includes a specified operation and one or more queryparameters. In other implementations, additional underlying protocolsare used for various purposes, such as SOAP (“Simple Object AccessProtocol”) for standard message exchange, WSDL (“Web ServicesDescription Language”) for description of service invocations, and UDDI(“Universal Description, Discovery, and Integration service”) fordiscovery of available services. In some situations, the application 122and Web service provider 140 may have a predefined relationship, whilein other embodiments the application may merely interact with a definedAPI for the provided Web service on behalf of the application'send-users without such a predefined relationship, such as if the Webservice provider is also a customer of the Access Manager system and isconfigured to accept and use credentials of the Access Manager system torepresent users.

After the user request for the operation that triggers the sign-on, asign-on request message is generated by the application (e.g., with adigital signature generated using the application's secret key to verifythat the requester is the application) and sent 184 to user interactionmanager process 152. If the message is verified, the access manager mayoptionally return 185 sign-on information to be used by the applicationin gathering sign-on information from the user (e.g., indications ofquestions to ask the user to gather information, or one or more pages orscreens to be displayed to the user if the application is so designed),and the application may perform the sign-on process with the user togather the various sign-on information (which in this example reflectsan account that the user has previously established with the accessmanager system). The gathered information may then be sent 186 to theaccess manager user interaction manager 152. In other embodiments, theapplication may instead gather sign-on information from the user withoutany initial interaction with the access manager system, and send thesign-on information for the user along with the initial request 184(e.g., depending on the level of permissions granted the application),although such a situation may expose the end-user's sign-on informationto the application. When the access manager user interaction manager 152receives the sign-on information, it sends 187 the sign-on informationto an account manager system 160, which uses information in a useraccounts database (“DB”) 162 to verify the sign-on information. Anindication of user authentication is then sent 188 back to the accessmanager user interaction manager, such as a user ID or an error message.If the sign-on information was valid, a request is sent 189 to thecredential manager 156 (e.g., with the user ID), and the credentialmanager generates a credential representing the user for use by theapplication and returns 190 the credential to the access manager userinteraction manager. After the access manager user interaction managerreceives the credential, it sends 191 the credential back to theapplication.

The application then generates a Web service request and sends 192 it tothe Web service provider 140, with the request optionally including adigital signature that is generated using the application's secretaccess key. When the Web service provider 140 receives the request, itoptionally verifies the identity of the requestor using the digitalsignature if attached (such as by sending a request to the AccessManager to request the verification, not shown). In addition, the Webservice provider verifies the user credential in this example by sending193 the credential to the credential manager, which generates theappropriate response (e.g., to validate the credential) and sends 194 itto the Web service provider. When the credential is validated, the Webservice provider provides the requested Web service for the user, andsends 195 a response to the application. The application can thenprovide corresponding information and/or functionality to the user basedon the response. In some embodiments, the application can further makevarious additional types of Web service and other requests, such as tointeract directly with the account manager system to make changes to theuser account or to retrieve data from the user account database 162.After all the requests are done, the user may sign out via theapplication or just allow the credential to expire after a limitedperiod of time during which it is valid.

FIG. 1C illustrates one example of various types of interactions betweena single sign-on Web service 101, an example customer Web site 103, anda Web browser 105 in use by an end-user (not shown) who is interactingwith the customer Web site. In this example, as a first step in theillustrated interactions, the end-user uses the browser 105 to send aHTTP-based request 121 to the customer Web site 103 to obtain indicatedfunctionality. The Web site determines that the requested functionalityis available only to signed-on users, and accordingly sends a sign-onrequest 123 to the end-user to perform a sign-on process. In thisillustrated embodiment, a digital signature is e attached to the sign-onrequest (e.g., using an X.509 certificate), as is generated in a mannerdescribed in greater detail elsewhere. In this example, the sign-onprocess is provided by the single sign-on service to numerous customerWeb sites, and the sign-on request 123 is sent to the browser 105 insuch a manner as to cause the browser 105 to forward the request 125including the digital signature to the single sign-on service (e.g., bysending a redirect URL, such as via an HTTP 301 status code). The singlesign-on service 101 then attempts to verify the digital signature of therequest 125, as described in greater detail elsewhere, and if itsucceeds it proceeds to send 127 a sign-on page back to the browser 105.The end-user then enters his/her sign-on information (e.g., username andpassword) in the sign-on page when displayed in the browser 105. Thesign-on page may be generated based on information provided during aprior registration by the user with the single sign-on service to createa corresponding user account (or after an interactive registrationprocess, not shown). The sign-on information is then transmitted back129 to the single sign-on service (e.g., when the end-user selects a“Done” control or other similar control). In this example, the end-usertrusts the single sign-on service provider, and is willing to sendhis/her sign-on information to the single sign-on service, especiallysince the sign-on information is not shared with the customer Web site103 in this example. After receiving the sign-on information, the singlesign-on service 101 determines whether the received sign-on informationis valid, and if so performs the sign-on of the end-user and generates acredential that represents the user as a signed-on end-user. Thegenerated credential is then sent 131 to the browser 105 in such amanner as to cause the credential to be forwarded 133 to the customerWeb site 103, such as via a cookie for the customer Web site or via aredirect URL. After the customer Web site receives the credential thatindicates the successful sign-on of the end-user, the customer Web site103 provides the initially requested functionality (not shown) to theend-user. While not shown here, the customer Web site may also use thecredential to take various subsequent actions on behalf of the end-user.For example, the credential may be returned to the single sign-onservice along with a request related to an account of the user (e.g., tomake payment based on financial information stored in the user account).Such credential-based use may be based on interactions directly betweenthe customer Web site 103 and the single sign-on service 101, or insteadvia interactions with one or more affiliated intermediate services (notshown) and/or the end-user. In addition, at least some of the variousmessages may be advantageously transferred over HTTP/S for securityreasons.

FIGS. 2A-2E illustrate examples of interactions between an accessmanager and a Web site or other service acting as a customer of theaccess manager in order to customize functionality to be provided tousers of the customer service. In particular, FIG. 2A illustrates afirst group of information that may be displayed to a representative ofa prospective customer service of the access manager, such as via a Webpage displayed to an operator of a service that is registering with theaccess manager in order to obtained customized functionality on behalfof users of the service. In this example, the initial registrationinformation includes instructional information 201, and a section 202 inwhich the access manager customer can specify various types ofinformation such as a name and Internet address 202 a (e.g., a URL of aWeb site that provides the service), administrative contact information202 b, and limited overview information about the service 202 c. Variousother types of information about the service and the operator of theservice can be obtained in various ways in other embodiments, and may beused as part of a determination of a level of trust and correspondingpermissions that the access manager will grant the access managercustomer, such as to restrict the types of customizations that are madeavailable to the customer. After the information is entered, theinformation is submitted to the access manager, in this example byclicking on the user-selectable “Register” control 203. Alternatively,the user-selectable “Reset” control 204 may instead be used to reset theinformation provided in the form. By selecting the “Register” control203 the prospective customer will in this example be presented with asubsequent group of information (e.g., a next Web page) as shown in FIG.2B to continue registration with the access manager. In otherembodiments, all of the information requests and customization controlsmay instead be presented in other manners (e.g., as part of a singlegroup of information that is displayed together).

FIG. 2B illustrates an example second group of information that may bedisplayed to a prospective customer service representative in order tospecify one or more types of co-branding customizations. In thisexample, the available types of co-branding customizations arerelatively minimal, such as to reflect a relatively low-level ofpermissions granted to the customer (e.g., as an initial default for anycustomer unless a higher level of trust can be verified, or based oninformation provided with respect to FIG. 2A and/or other informationavailable about the service or service operator, such as based on pastexperience of interactions with the service or operator). In thisexample, the customer is allowed to specify multiple brands and tocustomize information differently for each brand. In other embodiments,such brands may not be used or instead each combination of a service anda brand may be treated as a distinct customer. Similarly, while notshown here, in other embodiments a customer may be able to specify othertypes of distinctions for which different co-branding or othercustomizations are specified and used, such as multiple geographiclocales with which users may be associated or other groups of users.When specifying multiple brands, locales or other distinct groupings,each such grouping may in some embodiments be given a separateidentifier and optionally a separate secret access key, such as to allowreference to a particular grouping to be used. In this example, thedisplayed information includes a section 206 to indicate a brand beingconfigured (or to be left blank if distinct brands are not used or ifthe customizations are to apply to all brands), instructionalinformation 205, and an area 207 with various questions and informationselection/specification areas for the customer to specify one or morecustomizations. For example, the customer may specify one or more logoimages of the service (e.g., by uploading corresponding files orspecifying a network address from which the images may be retrieved) tobe displayed to users, with a specified logo image preview 208 beingshown in this example, as well as logo location to be used, text to bedisplayed to users, and a link to be displayed to users. As will beappreciated, a variety of other types of co-branding customizations maybe made available in other embodiments. In addition, in this example thecustomer is provided a user-selectable “Preview” control 209 with whichone or more sign-on pages or screens resulting from the specifiedco-branding customizations may be previewed, as well as auser-selectable “Save” control 210 to save the specified co-brandingcustomizations. In this example, the customer is illustrated asperforming only a single group of co-branding customizations, althoughin other embodiments multiple distinct sets of co-brandingcustomizations may be specified. For example, multiple distinct sets ofco-branding customizations may be provided for a single brand to reflectmultiple pages or other groups of information to be displayed to usersby the access manager (e.g., multiple pages used for the sign-on processand/or pages used for other related types of activities such as asign-off or sign-out process, gathering information from users,presenting errors, refreshing credentials, generating a new credentialfor a secondary service based on a credential issued to a primaryservice (referred to as “cloning” the credential), etc.).

In a manner similar to that of FIG. 2B, FIG. 2C illustrates analternative example second group of information that may be displayed toa prospective customer service representative in order to specify one ormore types of co-branding customizations. In this example, additionaltypes of co-branding customizations are available to the customer toreflect a relatively high-level of permissions granted to the customer(e.g., based on information provided with respect to FIG. 2A and/orother information available about the service or service operator). Inother embodiments, additional types of co-branding customizations may bemade available for other reasons (e.g., for premium customers, such asin exchange for additional fees). In this example, the displayedinformation includes indications 211 of the information 205-208 fromFIG. 2B, and further includes additional co-branding customizations 212.The additional types of co-branding customizations in this exampleinclude the ability. to further specify the appearance of information tobe displayed to users, to specify user-selectable controls and/or otherinformation to be included in a header of the page or other informationdisplayed to users, and to specify other executable code to be includedas part of the page or other information displayed or provided to users.These additional co-branding customizations types are merelyillustrative, however, and other additional types of customizations maybe available in alternative embodiments.

Although in this example an operator of or other representative of acustomer service individually specifies various customizations inresponse to corresponding prompts, in other embodiments other techniquesmay be used to specify co-branding customizations. For example, a WYSWYG(“What You See is What You Get”) system may be employed in someembodiments in which the customer graphically specifies an appearance ofa customized sign-on page or other information to be displayed orotherwise presented to users, or instead co-branding customizations mayinstead be specified in a file using an appropriate format (e.g., XML or(X)HTML (“(eXtensible) HyperText Markup Language”) fragments) and sentto the access manager.

FIG. 2D illustrates an example third group of information that may bedisplayed to a customer service representative in order to specify oneor more types of information gathering to be performed when interactingwith users of the service. In some embodiments, some or all of the typesof information gathering may only be available to customers with asufficiently high level of permission and/or based on other criteria(e.g., to be made available only to premium customers). In this example,various predefined types of information to gather are provided (e.g.,each with corresponding questions to be displayed to users, not shown),with checkboxes 213 available to select one or more of the predefinedinformation types. While not illustrated here, in at least someembodiments a customer service may further be able to configure one ormore sets of customer-specified questions to be asked of the users, suchas to type in the question to be asked and to optionally enumerate orotherwise indicate allowed answers to the question. In addition, thecustomer may further specify one or more types of user activities 215for the access manager to track in this example, such as sign-onattempts (successful and/or non-successful), sign-off attempts,obtaining agreement to displayed or otherwise indicated terms andconditions (e.g., as specified by the customer during the registrationprocess, not shown, and as accepted by a user via selection of an“Accept” control or via other indication of user assent). The customermay further specify the times to query users for predefined and/orcustomer-specified types of information in this example, as shown byuser-selectable timing control 214, although in other embodiments thetiming may instead be fixed (e.g., only once during a first sign-on (orother activity) by a user to a service, for each sign-on, etc.).Formatting information 216 may also be specified by the customer in thisexample, such as to indicate allowable types of answers for at leastsome of the predefined types of information to be gathered. In someembodiments, other types of information may also be supplied whileconfiguring information gathering, such as logic for use in dynamicallydetermining if user answers being supplied are permissible, logic foruse in determining if some questions are to be asked of a particularuser (e.g., questions about details regarding a spouse or child of auser, based on a prior answer from the user indicating whether the userhas a spouse or a child), etc.

FIG. 2E illustrates an example fourth group of information that may bedisplayed to a customer service representative in order to specify oneor more types of delegation of authority to other affiliated secondaryservices, such as to perform certain types of actions on behalf of usersof the primary customer service, although in some embodiments suchcustomizations may be provided to only customers with a sufficientlyhigh level of permission (and the specific types of authoritydelegations may vary based on the permission levels and/or otherfactors). In this example, FIG. 2E has instructional information 217,and sections 219, 221 and 223 via which the customer can specifyservices to receive delegations of authority. While not illustratedhere, the customer may further specify specific types of delegations ofauthority for each of the affiliated secondary services in someembodiments, such as by modifying a default set of authoritydelegations. The customer may further specify controls on information towhich an affiliated service will have access (e.g., a specified subsetof available user information). In this example, section 219 makesavailable various other services that are affiliated with the accessmanager (e.g., based on being provided by the same entity), such as apayment service (e.g., to enable payments to be made to and/or from auser's account) and a recommendation service (e.g., to obtain and/orprovide recommendations on behalf of a user, such as in accordance withpreviously specified preferences for the user). In addition, section 221makes available various other popular services (including in thisexample information about the service, such as a popularity orreliability rating), and section 223 allows the customer to specifyother services.

In some embodiments, a secondary service affiliated with the primarycustomer service may itself need to be registered with the accessmanager in order to interact with the access manager on behalf of auser, and thus the popular services may be based on the services alreadyregistered with the access manager. Alternatively, if a specifiedservice is not already registered with the access manager, the accessmanager may automatically query the specified service to offer theability to register. When the customer service is interacting with auser, the delegation of authority to another service may occur invarious ways, such as when initiated by the user (e.g., based on theuser selecting a link or control displayed by the primary customerservice that corresponds to capabilities provided via a secondaryservice, such as a link to make a payment from an account of the userthat will be delegated to a payment service) and/or if performedautomatically by the primary customer service. In addition, theinteractions with the secondary service may in some embodiments beperformed in a manner transparent to the user. For example, ifpayment-related capabilities are desired, a secondary affiliated paymentservice may generate and send a page or other group of information tothe user, such as to obtain corresponding information from the user(e.g., an indication of one or more other parties, a verification of theuser's sign-on or other information for at least some types of actions,etc.). In addition, in order to provide a consistent experience to theuser, the secondary affiliated service may in at least some embodimentsuse previously specified co-branding information for the primarycustomer service in the information displayed to the user. To obtainaccess to such previously specified co-branding, the secondaryaffiliated service may interact with the access manager to obtain theco-branding information if authority to use that co-branding informationhas been delegated to the secondary affiliated service. For example, theprimary customer service may delegate authority to the secondaryaffiliated service to be able to use specified types of co-brandinginformation for the primary customer service (e.g., one or more logos orother images of the primary customer service) in a specified manner, andif so the secondary service may gain use of such co-branding informationby sending an appropriate request to the access manager (e.g., a requestthat indicates the secondary service, the primary customer service, atype of information desired, and optionally specific co-brand inginformation of the primary customer service). If the access managerdetermines that the secondary service is authorized to use thatco-branding information, it will send back the co-branding information(or information that can be used by the secondary service to obtain theco-branding information).

FIGS. 3A-3B illustrate examples of a customized sign-on process providedby the access manager to users on behalf of a customer service. Inparticular, FIG. 3A illustrates an initial sign-on page that iscustomized for a customer service to be displayed to a user of theservice. In this example, the sign-on page may be generated by aprovider of the access manager functionality for a customer with arelatively low level of permissions (or who has not selected to includecustomizations associated with higher levels of permission). A customerlogo 301 and customer images 303 are displayed according to co-brandingcustomizations in this example, and a logo 305 of the access manager orthe entity providing the access manager is also shown. In otherembodiments, the logo 305 may not be used. Instructional information 307informs users to initiate the sign-on process using sign-on informationfor the account manager provider, such as based on accounts of the userswith the access manager provider. The sign-on information may then beentered in the appropriate spaces 309 by a user. In addition, customizedlinks 313 are displayed to provide access to the customer's conditionsof use and the customer's privacy policy. Various user-selectablecontrols 311 to submit the sign-on information are also presented.

FIG. 3B illustrates a subsequent page for the sign-on process that iscustomized for a customer service to be displayed to at least some usersof the service, such as users during their first sign-on to the customerservice or for subsequent sign-on attempts that meet specified criteria.In particular, in this example the page is provided to performcustomized types of information gathering by asking questions 325specified by the customer. Such questions may include, but are notlimited to, the shipping address, telephone number, and other contactinformation for the user. The customer logo 321 illustrates an exampleof various types of co-branding that may be present as part of theinformation gathering page, whether it is the same as logo 301 of FIG.3A or instead a distinct logo of the customer. Instructional information323 may also be presented to the user to inform him/her to answer thequestions, whether by default or as specified by the customer service.Some questions may also illustrate customized data formats specified bythe customer, such as for example telephone number 327. In someembodiments, client-side scripting (e.g., JavaScript) may be used toenforce any specified restrictions on allowable values, as well as toimplement specified logic for determining if some of the questionsshould be asked to the user. Additional queries 329 may be asked of auser every time the user signs-on to the customer, even if otherone-time information gathering is not being performed. After the userhas answered the questions, the user can submit the information by usingthe user-selectable controls 331.

The sign-on and information gathering may be done in various manners indifferent embodiments. For example, although FIGS. 3A and 3B show Webpages, in some embodiments other interfaces may be utilized, includingprogrammatically accessed interfaces. In addition, multiple pages may beused to gather information about a user, especially for the initialsign-on of a user to a customer, and various user interface widgets maybe used in the user interface.

Although not illustrated here, the customized sign-on process and othertypes of customized user interactions may also be used in a variety ofother situations and manners. For example, while the customizingtechniques were illustrated in FIGS. 3A and 3B as being used as part ofone or more Web pages, various other types of messages and informationmay instead be similarly customized, such as one or more email messages(e.g., email messages specified in HTML format) or other types ofelectronic messages sent to end-users. In addition, the techniques maybe used to co-brand various other types of information provided to auser, such as search engine results or information provided by a socialnetworking service.

FIG. 4 is a block diagram illustrating an example embodiment of anaccess manager computing system 400, as well as various user computingsystems 450, affiliated service computing systems 490 and customerservice computing systems 470. In the illustrated embodiment, the accessmanager computing system includes a CPU 405, various I/O components 410,storage 430, and memory 420, with the I/O components including a display411, a network interface 412, a computer-readable media drive 413, andother I/O devices 415.

Embodiments of the Access Manager system 423 and the Account Managersystem 428 are executing in the memory 420, and they interact with othercomputing systems over the network 480 (e.g. via the Internet and/or theWorld Wide Web). Users may first interact with the Account Managersystem in order to establish and use accounts (e.g., by each using abrowser 458 executing in memory 457 of a user computing system), such asto specify sign-on information, contact information, financialinformation, etc. that is stored in a user account database 432 datastructure on storage 430—in some embodiments, the Account Manager systemand/or one or more other affiliated systems (not shown) may furtherprovide a variety of types of functionality to users, such as onlineshopping functionality, messaging services functionality, informationaccess functionality, etc. The illustrated embodiment of the AccessManager system 423 includes several manager components to providevarious functionality, including a Customer Registration Managercomponent 421, a User Interaction Manager component 422, a CredentialManager component 424, a Customer Status Manager component 425, and aCustomer Verification Manager component 426, although in otherembodiments the functionality of the manager components may instead beorganized in other manners. The Customer Registration Manager componentinteracts with operators and other representatives of services toregister those services as customers of the Access Manager system and tocustomize sign-on and other functionality to be provided to users of theservices, with the customer-provided information being stored in acustomer information database 440 data structure on storage. After aprospective customer service has registered as a customer, one or moreusers may interact with services and other functionality provided bycustomer service computing systems, and be directed to the AccessManager system to perform a sign-on to the customer service. The UserInteraction Manager component will then interact with the user so as toprovide a customized sign-on process for the customer service, such asbased on previous stored user account information and/or based onregistering the user as a new user for the Account Manager system(whether directly or by re-directing the user to interact with theAccount Manager system). In addition, in some embodiments the UserInteraction Manager component will gather various information for theuser in a customized manner, and will store the information in thecollected user information database 436 data structure. If the sign-onattempt is successful, the Credential Manager component will generate acredential representing the user, store the credential information inthe credential database 438 data structure on storage, and return thecredential to the customer service (e.g., via a response to the userthat is re-directed back to the customer service) for storage as acredential 473 on storage 471 of a computing system of the customerservice, as well as to optionally provide any information gathered forthe user.

A customer service may then interact with the Account Manager and/orAccess Manager systems in order to perform various actions on behalf ofthe user (e.g., to modify and/or use account information of the user),such as by providing the credential representing the user. Under somecircumstances, a user may be directed by a customer service to anaffiliated service provided by an affiliated service computing system,with a credential issued to the customer service for the user beingprovided to the affiliated service and stored with credentials 493 onstorage 491 of the affiliated service computing system. The user maythen optionally be similarly re-directed by the affiliated service tointeract with the Access Manager system and/or Account Manager system inorder to perform actions on behalf of the user. Customer services (ortheir representatives) may also interact with the Customer StatusManager component to obtain various information about the service,including information about the service's own customer account with theAccess Manager system, and gathered user information from the collecteduser information database. In addition, in at least some embodimentssome customer services may each request that the Access Manager systemand Account Manager system provide additional customized functionalityto track and provide a variety of types of information about actions ofusers of the customer service, such as to make available to the customerservice most or all of the user-related information that the customerservice would have if it implemented its own sign-on service. If so,such user information is stored in an alternative user pool database 434data structure and is made available to those customer services by theCustomer Status Manager component, while similar detailed informationabout other users (or the same users when interacting with otherservices) is not made available to those customer services in theillustrated embodiment.

In at least some embodiments, a Customer Verification Manager componentis used to provide various additional security measures regardinginteractions of customer services with the Access Manager system and/orAccount Manager system. In particular, in such embodiments at least somemessages from customer services must include digital signatures that aregenerated based on information in the message and using a secret accesskey known to the service and to the Customer Verification Managercomponent (e.g., a secret access key determined during initialregistration of the service and stored in the service informationdatabase 440)—such digital signatures are generated by a customerservice in the illustrated embodiment via a Signature Generatorcomponent 478 executing in memory 477 of the computing system 470 of thecustomer service using a secret access key (not shown) of the customerservice. If so, the Customer Verification Manager component verifies theincluded digital signature (e.g., by replicating it by generating a newmatching digital signature using the secret access key for the customerthat is known to the component) in order to authenticate the receivedmessage before other of the systems or components respond to themessage. Such authentication of messages may further be performed for atleast some affiliated services in at least some embodiments andcircumstances. Furthermore, in some embodiments other types of messagesmay be similarly digitally signed using a secret access key of one ormore related services and authenticated based on the digital signatures.For example, these messages include messages from the Access Managersystem and/or Account Manager system to a customer service or affiliatedservice that are authenticated by the recipient service, messagesbetween customer services and affiliated services that are authenticatedwith the assistance of the Customer Verification Manager component(unless the services have access to the secret access keys of the otherservices), etc.

It will be appreciated that the illustrated computing systems are merelyillustrative and are not intended to limit the scope of the presentinvention. Access manager computing system 400 may be connected to otherdevices that are not illustrated, including through one or more networkssuch as the Internet or the Web. More generally, the various computingsystems may each comprise any combination of hardware and software thatcan interact in the manners described, including computers, networkdevices, Internet appliances, PDAs (“Personal Digital Assistants”),wireless phones, pagers, electronic organizers, television-based systemsand other various consumer products that include inter-communicationcapabilities. In addition, the functionality provided by the accessmanager system components illustrated in FIG. 4 may in some embodimentsbe combined in fewer components or distributed in additional components.Similarly, in some embodiments the functionalities of some of theillustrated components may not be provided and/or other additionalfunctionality may be available.

Those skilled in the art will also appreciate that, while various itemsare illustrated as being stored in memory or on storage while beingused, these items or portions of them can be transferred between memoryand other storage devices for purposes of memory management and dataintegrity. Alternatively, in other embodiments some or all of thesoftware components may execute in memory on another device andcommunicate with an illustrated computing system or device viainter-computer communication. Some or all of the access manager systemcomponents or data structures may also be stored (e.g., as instructionsor structured data) on a computer-readable medium, such as a hard disk,a memory, a network, or a portable article to be read by an appropriatedrive. The access manager components and data structures can also betransmitted as generated data signals (e.g. as part of a carrier wave)on a variety of computer-readable transmission mediums, includingwireless-based and wired/cable-based mediums. Accordingly, the presentinvention may be practiced with other computer system configurations.

FIG. 5 is a flow diagram of an example embodiment of the CustomerRegistration Manager routine 500. The routine may, for example, beprovided by execution of the Customer Registration Manager component 421of FIG. 4, such as to interact with operators and other representativesof services to customize sign-on and other functionality to be providedto users of the services.

The routine begins at step 505, where an indication is received from anoperator or other representative of a service to register the service asa customer with the access manager. After step 505, the routine receivesinformation in step 510 about the service (e.g., a service provided byor as part of a Web site), such as in an interactive manner bydisplaying a page asking for the information (e.g., as illustrated inFIG. 2A) or instead as part of a programmatically accessed API. Afterthe information is received at step 510, the routine determines whetheror not to accept the customer, such as based on whether the serviceand/or operator are determined to be sufficiently trustworthy (e.g.,using the information obtained in step 510) and/or based on othercriteria. If the customer is not accepted, the routine proceeds to step520 to send a registration denial message, and then continues to step590. Otherwise, at step 530 the routine determines a level ofpermissions to grant the customer, such as based on a degree of trustassessed for the service and/or the operator, and optionally based onfactors such as any liability of the access manager resulting fromactions of the service (e.g., based on a type of the service, a numberof users of the service, the types of co-branding and/or othercustomizations that the customer is enabled to use, such as if acustomer is allowed to specify and use executable code, etc.), any pastexperience between the access manager and the customer, etc. Inaddition, in some embodiments a customer may be charged more money toreceive a higher level of permissions (e.g., as part of a premiumservice) and thus gain additional functionality. The increased chargesmay be based at least in part on the customer's ability to and/orlikelihood of exposing the access manager to liability, such as byexposing confidential or sensitive user information to unauthorizedusers, by allowing unauthorized users to conduct financial transactionsor otherwise perform operations on behalf of users, etc. In at leastsome embodiments, the level of permissions for a customer may bereviewed and changed at later times. After the level of permissions hasbeen determined in step 530, depending on the permissions granted, theroutine determines whether to allow the customer to configure any brandsand if so whether the customer has any such brands. If so, the routineproceeds to step 540 where brands are configured as appropriate.

Otherwise, or after step 540, the routine proceeds to step 545 whereco-branding customization types that are available to the customeraccording to the determined level of permissions are displayed, such asfor a first of the brands and/or for all brands (if brands wereconfigured in step 540). In some embodiments, the display may be a Webpage, and may include a user interface similar to that of FIGS. 2Band/or 2C. After displaying the co-branding customization typesavailable, one or more indications of co-branding customizations areoptionally received by the routine at step 550 and stored for later use.In some embodiments, if multiple pages or other groups of informationmay be co-branded, each page may be separately configured. In step 555,predefined types of information gathering that are available to thecustomer according to the determined level of permissions are displayed,and one or more indications of information gathering customizations areoptionally received in step 560 and stored for later use. In step 565,predefined types of authority delegation that are available to thecustomer according to the determined level of permissions are displayed,and one or more indications of authority delegation customizations areoptionally received and stored for later use. In step 568, if multiplebrands were configured and are being customized individually, theroutine returns to step 545 to initiate configuration for the nextbrand, and if not the routine proceeds to step 570 to perform additionalprocessing if appropriate (e.g., storing various information inappropriate datastores, generating and providing to the customer aunique identifier and a secret access key, etc.). The routine thenproceeds to step 590 to determine whether to continue. If so, theroutine returns to step 505, and if not the routine ends at step 599.

The illustrated routine may be performed in other ways in alternativeembodiments. For example, although the routine shows that each brand maybe configured for multiple types of customizations, in some embodimentsbrands may only be able to have individually configured co-brandingcustomizations. In other embodiments, the customizations may bespecified in a different order, and if the access manager customer doesnot have permission for configuring a particular type of customization,the steps related to that type of customization may be skipped. Forexample, if a customer does not have permission to gather informationfrom the user, the routine may skip from step 550 to 565. While notillustrated here, in some embodiments the routine could additionally usevarious other security information and/or mechanisms, such as to verifythe identity of the customer's representative.

FIG. 6 is a flow diagram of an example embodiment of a User InteractionManager routine 600. The routine may, for example, be provided byexecution of the User Interaction Manager component 422 of FIG. 4, suchas to interact with a user on behalf of a customer service so as toprovide a customized sign-on process specified by the customer service.

In step 605, the routine receives an indication of a request regarding auser on behalf of a customer service, such as for the user to sign-onfor the service. In the illustrated embodiment, the request includes acustomer identifier associated with the customer and a digital signaturefor the request that is generated in a manner specific to the customer.The digital signature attached to the request is then checked by theCustomer Verification Manager routine (as illustrated in FIG. 9B), andif it is determined in step 610 to not be valid, the routine continuesto step 680 to send a failure notice and then continues to step 690. Ifthe signature is valid, the routine instead continues to step 615 todetermine the type of the request If the request is for something otherthan sign-on, the requested operation is performed as appropriate instep 685. If the request is a sign-on request, the previously configuredcustomizations for the customer associated with the received customeridentifier are retrieved in step 620, and in step 625 a sign-on page isgenerated with the customized co-branded content and sent to the user.Then, at step 630, the routine determines if the user has an accountwith the access manager, and if not, the routine obtains informationabout the user and registers the user with the access manager in step640. If the user already has an account with the access managerprovider, then sign-on information is received from the user at step635, and in step 645 it is determined whether the sign-on information isvalid (e.g., matches the stored sign-on information for the user). Ifthe sign-on information is not valid, then the routine continues to step680 to send a failure notice to the user.

If the sign-on information is valid, or after step 640, then at step 650a credential or other indication of the valid sign-on of the user isgenerated to be provided to the service (or in other embodiments to beprovided to the user for use with one or more services, such as for aspecified period of time or according to other indicated criteria). Theroutine then determines in step 655 whether to retrieve additionalinformation about the user to be provided to the service (e.g., ausername, unique identifier, actual name, etc.), such as based on priorcustomizations and current circumstances, and if so continues to step660 to retrieve the additional information as appropriate. In someembodiments, the ability of a customer service to obtain this additionalinformation may be restricted by the level of permissions granted to thecustomer. After step 660, or if no additional information was retrieved,the routine then determines at step 665 whether any information is to begathered about the user, such as based on prior customizations andcurrent circumstances, and if so continues to step 670 to gather theinformation about the user as appropriate. After step 670, or if noinformation was gathered, the credential and optionally other data(e.g., the retrieved and/or gathered information) is sent to thecustomer, such as via the user using HTTP redirect functionality. Aftersteps 675, 680 or 685, the routine determines whether to continue instep 690. If so, the routine returns to step 605, and if not ends atstep 699.

FIG. 7 is a flow diagram of an example embodiment of a CredentialManager routine 700. The routine may, for example, be provided byexecution of the Credential Manager component 424 of FIG. 4, such as togenerate credentials representing users and to perform othercredential-related activities.

The routine begins at step 705 where a credential-related request isreceived, such as from an external service or another access managercomponent—depending on the request, the request may also containadditional parameters, including an existing credential on which toperform the request. After the request is received, the routine proceedsto step 710 where it is determined if the received request is togenerate a new credential to represent a user for a service, such asfrom the User Interaction Manager component. If so, the credential iscreated as appropriate in step 715 (such as by mapping a unique randomnumber to the user, or retrieving information about the user forinclusion as part of the credential), and the routine continues to step770 to store the credential and optionally provide in to the requester.If the request was not to generate a credential, then the routinedetermines in step 720 if the request is to refresh an existingcredential to extend its period of validity, such as from a service towhich the credential was initially issued. If so, the routine determinesin step 722 whether the requester has permission to refresh thecredential (e.g., based on a level of permission granted to therequester and/or information specified by the user represented by thecredential, such as during the sign-on to the service). If permissionexists, then the credential is refreshed in step 724 before the routinecontinues to step 770. If there is not enough permission to refresh theuser credential, then an error message is indicated at step 729 and theroutine proceeds to step 795.

If it is determined in step 720 that the request is not to refresh thecredential, the routine proceeds to step 730 to determine if the requestis to clone an existing credential, such as a request from a secondaryaffiliate service to obtain use of a credential for a user that wasissued to a primary customer service with which the secondary service isaffiliated. If so, the routine continues to step 732 to determinewhether the credential cloning is authorized, such as based on authoritydelegated to the secondary service from a primary service. In addition,in some embodiments the cloning of a credential representing a user mayinvolve requesting the user to provide information and to optionallyapprove or otherwise acknowledge the cloning, and in such embodimentsthe determination of whether the cloning is authorized may further bebased at least in part on the user actions. If it is determined in step732 that permission exists, then in step 734 the credential is clonedand the routine continues to step 770, and if not then at step 739 anindication is sent that an error occurred and the routine proceeds tostep 795.

If it is determined in step 730 that the request is not to clone acredential, then the routine proceeds to step 740 to determine if therequest is to verify whether a credential is valid. If so, then theroutine determines in step 745 if the credential is currently valid forthe requestor and optionally for an indicated action, and sends anindication of the credential's validity to the requester. If the requestis not to determine if a credential is valid, then at step 750 theroutine determines if the request is to determine when the credentialwill expire. If so, then at step 755 the routine determines theexpiration and indicates it to the requester, and if not the routinecontinues to step 760 to respond to other types of requests asappropriate. After steps 729, 739, 745, 755, 760 or 770, the routinedetermines at step 795 whether to continue. if so, the routine returnsto step 705, and if not ends at 799.

FIG. 8 is a flow diagram of an example embodiment of a Customer StatusManager routine 800. The routine may, for example, be provided byexecution of the Customer Status Manager component 425 of FIG. 4, suchas to provide various types of information to customers.

The routine begins at step 805, where a request is received from acustomer. In step 810, the routine determines if the request isauthorized, such as by interacting with the Customer VerificationManager component and/or based on the level of permissions granted tothe customer. If not, the routine proceeds to step 895, but otherwisedetermines in steps 815-860 whether the customer has requested to modifyvarious types of information and if so performs the modifications asappropriate. Types of information that may be modified by the customerin the illustrated embodiment include co-branding customizations (insteps 815 and 820), information gathering customizations (in steps 825and 830), authority delegation customizations (in steps 835 and 840),brands (in steps 845 and 850), and customer account information (insteps 855 and 860). If the received request is not to modifyinformation, the routine determines in step 865 if the request is tomonitor users. If so, previously tracked user information is retrievedin step 870 and provided to the customer, and if not the routinecontinues to step 875 to perform other requested functionality asappropriate. After steps 820, 830, 840, 850, 860, 870 and 875, or if itwas determined in step 810 that the request was not authorized, theroutine continues to step 895 to determine whether to continue. If so,the routine returns to step 805, and if not ends at step 899.

FIGS. 9A and 9B are flow diagrams of an example embodiment of routinesfor authenticating received messages, with FIG. 9B illustrating anexample embodiment of a Verification Manager routine 925 and with FIG.9A illustrating an example embodiment of a corresponding Client-SideVerification routine 900. The Verification Manager routine may, forexample, be provided by execution of the Customer Verification Managercomponent 426 of FIG. 4, such as to provide various additional securitymeasures regarding incoming messages from customer services and otherservices. The Client-Side Verification routine may, for example, beprovided by a computing system of a customer service in conjunction withthe Signature Generator component 478 of FIG. 4, such as to useadditional security measures for outgoing messages to the accessmanager.

The client-side routine 900 of FIG. 9A begins at step 905, where anindication to generate an outgoing message from a customer service thatis to include various information is received, and in which variousinformation is gathered for use in generating a customer-specificdigital signature to accompany the message for security purposes. Insome embodiments, information used in generating the signature includesat least some of the content of the message, as well as otherinformation that is not included such as a secret access key. Inaddition, in some embodiments other information may be added to theinformation used in generating the signature, such as a currenttimestamp (e.g., to prevent the message from later being reused ifintercepted). The messages to be sent may have various forms, includingan HTTP request sent using a URL or other URI (“Uniform ResourceIdentifier”) in which the message contents are included as part of oneor more query string parameter values and in which the digital signaturewill be included as a value of another query string parameter. In step910, the routine generates a digital signature based on the gatheredinformation, such as by using a previously selected digital signaturealgorithm and using previously selected types of message information(e.g., particular message parameter values in a particular order). Instep 915, the signature is added to the message before it is sent out,and the routine then ends at step 920 until a next signed message is tobe sent.

The Verification Manager routine 925 of FIG. 9B begins at step 927,where a request for verification of an incoming message is received,such as a request received from access manager system or one of itscomponents regarding a message received from a customer service or anaffiliated service. At step 930, the routine first determines if themessage is sufficiently recent, such as based on whether time elapsedfrom a timestamp attached to the message exceeds a predetermined periodof time. If the timestamp is too old, the routine sends an indication instep 970 that the signature is invalid, and additional processing asappropriate is optionally performed in step 975 (e.g., generating anotification if a pattern of invalid messages is seen). Then, theroutine proceeds to step 995.

If the timestamp was sufficiently recent, then the routine proceeds tostep 935 to retrieve the stored secret access key for the customer fromwhom the message was received, such as based on an identifier assignedto the customer that is included in the message and associated with thesecret access key. In other embodiments, the customer or otheraffiliated service may be identified in other ways such as based on theIP address from which the request is received. After retrieving thesecret access key and any additional information about the customer instep 935, the routine generates a digital signature for the message atsteps 940 and 945 in the same manner as that described previously withrespect to steps 905 and 910 of FIG. 9A, such as to use informationincluded in the message (not including the digital signature) and theretrieved secret access key. In step 950, the newly generated signatureis then checked against the signature included in the message. If thetwo digital signatures are determined in step 955 to be the same, themessage is verified and a corresponding confirmation is sent in step960. If the message is not verified, it is considered a forgery and acorresponding indication is sent in step 965. After steps 960, 965 or975, the routine proceeds to step 995 where it determines whether tocontinue. If so, then the routine returns to step 927, and if not endsat step 999.

While not illustrated here, in some embodiments similar techniques maybe used by services to verify messages from the access manager. Inaddition, various embodiments may have additional security features andmechanisms beyond the signature-based verification illustrated in FIGS.9A and 9B, such as to gather information regarding the identity of arepresentative of a service when the representative is initiallyregistering the service.

Thus, various techniques may be used to provide customizable sign-on andother functionality to services, as well as to use various techniques toenhance security of interactions. In addition, in some embodiments avariety of additional information and techniques may be used. Forexample, customers of the access manager customers may include Web sites(such as ecommerce sites) and may be unrelated to the provider of theaccess manager. The level of permissions granted to a customer by theaccess manager may also vary, such as to grant a higher level ofpermissions to well-known respected sites than to unknown sites. Inaddition, a low level of co-branding permissions may only allow anaccess manager customer to specify images and text to be—used, while anaccess manager customer with higher-level permissions may be able to addimages, image maps (to provide functionality when a user selects anypart of or a designated portion of the image), specified types ofuser-selectable functionality (e.g., a header with dropdown buttons),text, links, background music, JavaScript code, Flash animations,Shockwave movies, Java applets, custom CSS (“Cascading Style Sheets”)styles, etc. In some embodiments, the granting of permissions happensautomatically in a realtime or near-realtime process, while in otherembodiments the process may take longer (e.g., to allow for manualreview of the service). In addition, in some embodiments the level ofpermissions granted to a customer may be reviewed and modified, such ason a periodic basis. For example, if problems or concerns with acustomer have arisen, the level of permissions may be decreased.Conversely, the level of permissions may be increased if no suchproblems have occurred, such as to grant some or all new customers lowlevels of permission that are gradually increased if warranted bycontinued experience with the customer. For example, permissions may beincreased based on an analysis or review of traffic and/or usagepatterns by or on behalf of the customer. In some embodiments, reviewsof the level of permissions granted may be triggered by externalfactors, such as news about or changes to the customer (e.g., a mergeror buyout of a customer, bankruptcy, etc.).

A variety of types of services may be used as affiliated services,including (but not limited to) payment processors, credit cardverification services, consumer survey services, advertising services,fulfillment services, etc., and in some embodiments the provider of theaccess manager may offer some of its services as affiliated services.Affiliated services may in some cases be provided access to a subset ofthe information for a customer or a user to facilitate providing theirservices—for example, a consumer survey service may want to know when aparticular product shipped to a consumer as well as contact informationin order to perform follow-up with the consumer about the product andservice.

A message or other request sent from a service to the access manager maytake a variety of forms in various embodiments. In some embodiments, arequest may be an HTTP message with message parameters or other contentspassed as a query string, and at least some information (e.g., secretaccess keys, confidential user sign-on information and other userinformation, etc.) is preferably sent by secure means (e.g., secureHTTP) or in an offline manner (e.g., via physical mail, telephone,etc.). Similarly, a user's sign-on information or other identifyinginformation may have various forms, such as a username and password,various biometric information, PKI-based information, etc. In someembodiments, credentials may be exchanged as Web browser cookies, oralternatively in a format specified by the WS-Federation Passive Profile(e.g., a WS-Trust RequestSecurityTokenResponse XML element) or based onanother sign-on specification standard (e.g., based on the LibertyAlliance Project, on Microsoft's Passport service, etc.). Similarly, insome embodiments a sign-on process may be performed in various ways,such as via the process specified in WS-Federation Passive RequestorProfile.

As previously noted, in some embodiments at least some customer servicesmay request the establishment and use of an alternative data pool forusers of the service, such as to track a variety of types ofinteractions with the users. For example, alternative data pools maystore information about users such as purchases, products or servicesviewed, login times, information modifications that are made, andpossibly information about historical or other activities of the usersthat are not specific to the customer service, and in some embodiments acustomer may be allowed to configure what data to store in thealternative data pool. In some embodiments, the availability of analternative data pool to a customer may be dependent on the level ofpermissions granted to the customer.

In some embodiments, secret access keys may be modified or re-generated,such as periodically or if compromised. In addition, additional securitymay be obtained by maintaining information about how to use the secretaccess key available only to appropriate recipients, and moreover tooptionally using different processes for different customers. In someembodiments, an indicated process may include a list of parameters whosevalues for a message are to be included, an ordering of the messageparameters, and a type of encoding to use, and a process may beindicated to a customer in various manners (e.g., documentation for useby a service operator in manually incorporating the process into theservice, executable code to be given various input so as to perform theprocess, etc.). A digital signature may be generated in various ways,such as by using a message authentication code (e.g., HMAC (“keyed-HashMessage Authentication Code”) with MD5 (“Message Digest algorithm 5”)).

Those skilled in the art will also appreciate that in some embodimentsthe functionality provided by the routines discussed above may beprovided in alternative ways, such as being split among more routines orconsolidated into fewer routines. Similarly, in some embodimentsillustrated routines may provide more or less functionality than isdescribed, such as when other illustrated routines instead lack orinclude such functionality respectively, or when the amount offunctionality that is provided is altered. In addition, while variousoperations may be illustrated as being performed in a particular manner(e.g., in serial or in parallel) and/or in a particular order, thoseskilled in the art will appreciate that in other embodiments theoperations may be performed in other orders and in other manners. Thoseskilled in the art will also appreciate that the data structuresdiscussed above may be structured in different manners, such as byhaving a single data structure split into multiple data structures or byhaving multiple data structures consolidated into a single datastructure. Similarly, in some embodiments illustrated data structuresmay store more or less information than is described, such as when otherillustrated data structures instead lack or include such informationrespectively, or when the amount or types of information that is storedis altered.

From the foregoing it will be appreciated that, although specificembodiments have been described herein for purposes of illustration,various modifications may be made without deviating from the spirit andscope of the invention. Accordingly, the invention is not limited exceptas by the appended claims and the elements recited therein. In addition,while certain aspects of the invention are presented below in certainclaim forms, the inventors contemplate the various aspects of theinvention in any available claim form. For example, while only someaspects of the invention may currently be recited as being embodied in acomputer-readable medium, other aspects may likewise be so embodied.

1-68. (canceled)
 69. A non-transitory computer-readable medium havingstored contents that cause a computing system of a sign-on service to:authorize, by the computing system, a user based on a match betweensign-on information that is received for the user and stored sign-oninformation in an account of the user with the sign-on service; provide,by the computing system, a credential to a second service that is acustomer of the sign-on service, wherein the user is interacting withthe second service, and wherein the credential is generated by thesign-on service to represent the user based at least in part on theauthorizing of the user; receive, by the computing system and after theproviding of the credential, a request from the second service to obtainfinancial information for the user that is stored by the sign-on servicein the account of the user, wherein the received request includes thecredential; and send, by the computing system and based on thecredential included in the received request, the financial informationfor the user over one or more computer networks to the second service.70. The non-transitory computer-readable medium of claim 69 wherein thestored contents include instructions that, when executed, further causethe computing system to: before the authorizing of the user, registerthe second service with the sign-on service; and after the registeringof the second service, receive, by the computing system, a sign-onrequest for the user to the second service, wherein the received sign-onrequest includes the sign-on information received for the user, andwherein the authorizing of the user is performed in response to thereceived sign-on request.
 71. The non-transitory computer-readablemedium of claim 69 wherein the stored contents further cause thecomputing system to determine that the second service is authorized toaccess the financial information for the user, and wherein at least oneof the providing of the credential or the sending of the financialinformation is performed based at least in part on the determining thatthe second service is authorized.
 72. The non-transitorycomputer-readable medium of claim 69 wherein the stored contents furthercause a second computing system of the second service to receive thesent financial information for the user and to use the financialinformation to initiate a payment from the user to the second service.73. The non-transitory computer-readable medium of claim 69 wherein thereceived request is further for the sign-on service to make a paymentfrom the user to the second service, and wherein the stored contentsfurther cause the computing system to use, based at least in part on thecredential being included in the received request, the financialinformation to initiate the payment from the user to the second service.74. A computer-implemented method comprising: authorizing, by one ormore computing systems providing an access manager system, a user basedon identifying information received for the user; after the authorizingof the user, receiving, by the one or more computing systems, a requestfrom a first service to obtain information for the user that is storedby the access manager system, wherein the received request includes acredential representing the user; retrieving, by the one or morecomputing systems, the information for the user that is stored by theaccess manager system; and sending, by the one or more computing systemsand based on the credential included in the received request, theretrieved information for the user over one or more computer networks tothe first service.
 75. The computer-implemented method of claim 74wherein the access manager system provides sign-on services to at leastthe first service, and wherein the identifying information received forthe user is sign-on information stored by the access manager system forthe user.
 76. The computer-implemented method of claim 74 wherein theuser has an account accessible to the access manager system thatincludes financial information for the user, and wherein the informationfor the user that is retrieved and sent to the first service includesthe financial information for the user.
 77. The computer-implementedmethod of claim 76 further comprising, by a second computing system ofthe first service, receiving the sent financial information for theuser, and using the financial information to initiate a payment from theuser.
 78. The computer-implemented method of claim 74 wherein thereceived request is further for the access manager system to cause apayment to be made from the user to the first service, and wherein themethod further comprises using, by the one or more computing systems,stored financial information for the user to initiate the payment fromthe user to the first service.
 79. The computer-implemented method ofclaim 74 wherein the information for the user that is retrieved and sentto the first service includes at least one of contact information forthe user or information about an identity of the user, to enable thefirst service to further interact with the user based on the at leastone of the contact information or the information about the identity.80. The computer-implemented method of claim 74 further comprising, bythe one or more computing systems: receiving, before the receiving ofthe request, instructions from the first service to gather one or morespecified types of information from users who use the access managersystem to obtain access to the first service; and gathering, based atleast in part on the instructions from the first service, informationfrom the user for the one or more specified types of information, andwherein the information for the user that is retrieved and sent to thefirst service includes the gathered information from the user, to enablethe first service to perform further interactions based on the one ormore specified types of information.
 81. The computer-implemented methodof claim 74 wherein the authorizing of the user is further based in parton information stored in an account of the user with the access managersystem, and wherein the retrieving of the information for the user thatis stored by the access manager system includes retrieving at least someof the information stored in the account of the user with the accessmanager system.
 82. The computer-implemented method of claim 74 whereinthe access manager system stores information about one or more types ofinteractions by the user with at least one of the first service or theaccess manager system, and wherein the retrieving of the information forthe user that is stored by the access manager system includes retrievingat least some of the stored information about the one or more types ofinteractions.
 83. The computer-implemented method of claim 82 whereinthe stored information about the one or more types of interactions bythe user includes information about at least one of purchases made bythe user with the first service or about products viewed by the user atthe first service, and wherein the method further comprises performing,by the first service, further interactions with the user based at leastin part on the retrieved at least some stored information.
 84. Thecomputer-implemented method of claim 82 wherein the stored informationabout the one or more types of interactions by the user includesinformation about modifications made by the user to information at thefirst service.
 85. The computer-implemented method of claim 82 whereinthe stored information about the one or more types of interactions bythe user is part of an alternative data pool maintained by the accessmanager system for the first service.
 86. The computer-implementedmethod of claim 74 further comprising obtaining, by the one or morecomputing systems, acceptance by the user of one or more specified termsfor interacting with the first service, and wherein the information forthe user that is retrieved and sent to the first service includesinformation about the acceptance by the user of the one or morespecified terms, to enable the first service to further interact withthe user based on the acceptance by the user of the one or morespecified terms.
 87. The computer-implemented method of claim 74 furthercomprising, before the sending of the retrieved information to the firstservice: determining, by the one or more computing systems, that thefirst service is authorized to receive stored information for the user;and providing, by the one or more computing systems, the credential tothe first service to enable the first service to make subsequentrequests to the access manager system on behalf of the user.
 88. Asystem comprising: one or more hardware processors of one or morecomputing systems; and a memory including instructions that, uponexecution by the one or more hardware processors, cause the system toimplement an access manager system and to: authorize a user based onsign-on information that is received for the user; provide a credentialto a first service with which the user is interacting, wherein thecredential is provided by the access manager system to represent theuser based at least in part on the authorizing of the user; receive,after the providing of the credential, a request from the first serviceto use stored financial information for the user to cause a payment fromthe user to the first service, wherein the received request includes thecredential; initiate, based on the credential included in the receivedrequest, the payment from the user to the first service; and sendinformation regarding the payment over one or more computer networks tothe first service.
 89. The system of claim 88 wherein the sending of theinformation to the first service includes sending the financialinformation for the user from the access manager system to the firstservice.